View COREPCI-M_871867.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

october 2004 v 4 .0 1 ? 2004 actel corporation corepci v5.41 product summary intended use ? most flexible high-performance pci offering ? target, master, and master/target, which includes target+dma and target+master functions ? 33 mhz or 66 mhz performance ? 32-bit or 64-bit pci bus widths ? memory, i/o, and configuration support backend support for syn chronous dram, sram, and i/o subsystems key features two user-configurable base address registers for target functions interrupt capability built-in dma controller in all master functions flexible backend data flow control hot-swap extended ca pabilities support for compact pci data transfer rates fully compliant zero-wait-state burst (32-bit or 64-bit transfer each cycle) optional paced burst (wait states inserted between transfers) supported families proasic3/e proasic plus 1 axcelerator rtax-s sx sx-a rtsx-s 1 design source provided vhdl and verilog-hdl design source actel-developed testbench synthesis and simu lation support synthesis: exemplar tm , synopsys ? dc / fpga compiler tm , and synplicity ? simulation: vital-complia nt vhdl simulators and ovi- compliant verilog simulators macro verification and compliance actel-developed testbench hardware tested i/o drive compliant in targeted devices compliant with the pci 2.3 specification version this datasheet defines the functionality of version 5.41 for corepci. contents general description ................................................... 2 corepci device requirements ................................... 3 utilization statistics ................................................... 5 corepci ip functional block diagram ....................... 6 data transactions ....................................................... 6 i/o signal descriptions ............................................... 6 corepci target function .......................................... 12 corepci master function ......................................... 17 master register access ............................................. 19 system timing .......................................................... 22 pci target transactions ............................................ 22 pci master transactions ........................................... 35 backend control of dma activity ........................... 38 ordering information .............................................. 40 list of changes ......................................................... 41 datasheet categories ............................................... 41
corepci v5.41 2 v4.0 general description corepci connects i/o, memory , and processor subsystem resources to the main system via the pci bus. corepci is intended for use with a wide variety of peripherals where high-performance data transactions are required. figure 1 on page 2 depicts typical system applications using the baseline ip core. while corepci can handle any transfer rate, most applications will operate at zero wait states. when required, wait states can automatically be inserted by a slower peripheral. the core consists of up to four basic units: the target controller, the master contro ller, the backend, and the wrapper. both the target and master controllers remain constant for a variety of backends. a backend controller provides the necessary cont rol for the i/o or memory subsystem and interfaces to the target controller through a generic interface. the wrapper combines the target and master blocks with the backend for implementation in a single actel device. corepci can be customized in two different ways. first, a variety of variables are provided to easily change parameters such as memory and i/o sizes. the second method is to develop user-specific backend controllers for non-standard peripherals. figure 1 ? corepci system block diagram mem_address bus mem_data bus corepci target+master controller memory subsystem sync sram sync dram optional memory or i/o subsystem bar1_enable memory control signals master bridge target framen irdyn stopn devseln trdyn serrn idsel ad par cbe perrn intan clk rstn pci bus backend controller reqn gntn req64n ack64n par64 system cpu master control signals
corepci v5.41 v4.0 3 corepci device requirements performance requirements and bus size both drive device selection. table 1 summarizes the device requirements. a typical 64-bit pci system requires at least 200 i/os. table 4 on page 5 shows typical pin counts. the actual number of i/o pins depends on the user backend interface. the table assumes the complete backend interface is connected to i/o pins rather than internal logic. some applications such as pci-uar t target could only require one backend i/o pin. table 1 and table 2 on page 4 are summaries of the minimum device requirements for various pci size/performance options. in order to meet the pci timing requirements for output valid (6 ns for 66 mhz, 11 ns for 33 mhz) and input setup (3 ns for 66 mhz, 7 ns for 33 mhz) times, the speed grades shown in table 1 must be used. the rtsx-s, proasic, and proasic plus families should only be employed for 32-bit/ 33 mhz pci applications. table 1 supported devices family pci voltage smallest devi ce commercial industrial military 33 mhz 32-bit sxa 3.3 & 5.0 a54sx16a std std std rtsx-s 3.3 & 5.0 rt54sx32s ?1 ?1 ?1 ax 3.3 ax125 std std std rtax-s 3.3 rtax250s std ?1 ?1 apa 3.3 apa075 std std std proasic3/e 3.3 a3p125 std std std 33 mhz 64-bit sxa 3.3 & 5.0 a54sx16a std std std rtsx-s 3.3 & 5.0 rt54sx32s n/a n/a n/a ax 3.3 ax125 std std std rtax-s 3.3 rtax 250s ?1 ?1 ?1 apa 3.3 apa075 n/a n/a n/a proasic3/e 3.3 a3p125 std std std 66 mhz 32-bit sxa 3.3 & 5.0 a54sx16a ?3 ?3 n/a rtsx-s 3.3 & 5.0 rt54sx32s n/a n/a n/a ax 3.3 ax125 ?1 ?1 o/r rtax-s 3.3 rtax1000s n/a n/a o/r apa 3.3 apa075 n/a n/a n/a proasic3/e 3.3 a3p125 -2 -2 n/a 66 mhz 64-bit sxa 3.3 & 5.0 a54sx16a ?3 ?3 n/a rtsx-s 3.3 & 5.0 rt54sx32s n/a n/a n/a ax 3.3 ax125 ?1 ?1 o/r rtax-s 3.3 rtax1000s n/a n/a o/r apa 3.3 apa075 n/a n/a n/a proasic3/e 3.3 a3p125 -2 -2 n/a notes: 1. required speed grades based on libero design flows. 2. n/a indicates device not supported. 3. all packages are supported. 4. o/r indicates on request.
corepci v5.41 4 v4.0 table 2 device utilization for corepci functions target master target+dma target+master device 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit a54sx16a 54% n/a 89% n/a 86% n/a 94% n/a a54sx16p 54% n/a 89% n/a 86% n/a 94% n/a a54sx32a 27% 32% 45% 56% 43% 57% 48% 56% a54sx72a 13% 15% 21% 27% 21% 27% 23% 27% rt54sx32s 27% 32% 45% 27% 43% 57% 48% 56% rt54sx72s 13% 15% 21% 27% 21% 27% 23% 27% ax125 39% 45% 64% 79% 62% 81% 68% 80% ax250 19% 22% 31% 38% 30% 39% 32% 38% ax500 10% 11% 16% 20% 16% 20% 17% 20% ax1000 4% 5% 7% 9% 7% 9% 8% 9% ax2000 2% 3% 4% 5% 4% 5% 4% 5% rtax250s 19% 11% 16% 20% 16% 20% 17% 20% rtax1000s 4% 5% 7% 9% 7% 9% 8% 9% rtax2000s 2% 3% 4% 5% 4% 5% 4% 5% apa075 40% n/a 62% n/a 62% n/a 80% n/a apa150 20% n/a 31% n/a 31% n/a 40% n/a apa300 15% n/a 23% n/a 23% n/a 30% n/a apa450 10% n/a 16% n/a 16% n/a 20% n/a apa600 6% n/a 9% n/a 9% n/a 11% n/a apa750 4% n/a 6% n/a 6% n/a 7% n/a apa1000 2% n/a 3% n/a 3% n/a 4% n/a a3p125 45% 49% 72% 90% 72% 90% 76% 90% a3p250 22% 25% 36% 45% 36% 45% 36% 45% a3p400 15% 17% 24% 36% 24% 36% 26% 36% a3p600 10% 11% 16% 20% 16% 20% 17% 20% a3p1000 5% 6% 9% 11% 9% 11% 10% 11% a3pe600 10% 11% 16% 20% 16% 20% 17% 20% a3pe1500 3%4%6%7%6%7%6%20% a3pe3000 2%2%3%4%3%4%3%4% notes: 1. refers to the sx, sx-a, rtsx, and rtsxs families. 2. n/a indicates either insufficient i/o resources, or the device does not support 66 mhz operation. 3. table 3 on page 5 gives more detailed utilization data. 4. utilization will vary depending on core conf iguration, table shows typical values. 5. all packages are supported fo r the devices listed above.
corepci v5.41 v4.0 5 utilization statistics utilization statistics are given in table 2 on page 4 . table 3 gives a detailed breakdown of the actual gate counts for each of the core variations and options listed in table 3 . the antifuse column indicates the typical r and c module counts for the sx, sx-a, rtsx-s, and axcelerator families. the flash column indicates the tile counts for the proasic plus and proasic3/e families. these are typical numbers a nd will vary based on the synthesis tools and constraints used. each backend requires different amounts of logic depending on the complexity of the controller. an sdram controller is included as an example. table 3 utilization statistics for corepci function antifuse 1 proasic plus flash 2 proasic3/e flash 2 sequential combinatorial total tiles tiles 32-bit target controller 262 528 790 1218 1194 64-bit target controller 350 560 910 n/a 1266 32-bit master controller 480 810 1290 1900 1862 64-bit master controller 600 1000 1600 n/a 2590 32-bit target+dma controller 400 850 1250 1904 1866 64-bit target+dma controller 554 1087 1641 n/a 2815 32-bit target/master controller 470 900 1370 2437 2389 64-bit target/master controller 570 1050 1620 n/a 2720 sdram controller 70 130 200 230 225 bar #1 support 30 70 100 140 137 dma mapped into i/o 3 30 90 120 120 117 notes: 1. the sequential number is the r-module usage and the combinatorial number is the c-module usage. 2. total number of tiles required. 3. only applicable to target+dma functions. table 4 core i/o requirements core i/o count pci backend total minimum standard* minimum standard* 32-bit target controller 48 1 74 49 122 64-bit target controller 87 1 113 88 200 32-bit master controller 50 1 83 51 133 64-bit master controller 89 1 122 90 211 32-bit target+dma controller 50 1 74 51 124 64-bit target+dma controller 89 1 113 90 202 32-bit target+master controller 50 1 83 51 133 64-bit target+master controller 89 1 122 90 211 note: *assumes all the backend i/o pins as listed in the data sheet are connected to i/o pins rather than to internal fpga logic.
corepci v5.41 6 v4.0 corepci ip functional block diagram corepci consists of six majo r functional blocks, shown in figure 2 on page 7 . these blocks are the dma state machine, the address ph ase state machine, the dataphase state machine, the datapath, parity, and the configuration block. all of the blocks shown are required to implement the target+dma and target+master functions. for the target-only core, the dma state machine is eliminated. for the master-only core, the configuration block is not required. the dma, address phase, an d dataphase state machines control the core?s outputs and also the dataflow between the pci bus and th e backend. the remaining modules define the datapath logic for corepci. dma state machine the dma state machine is responsible for obtaining master ownership of the pci bus and launching a data transfer by asserting framen. once a burst transaction has begun, the dma state ma chine tracks the transfer count and terminates the burst by de-asserting the framen signal and releasing master ownership of the pci bus. in addition to basic master control, the dma module also implements the dma support registers, pci start address, ram start address, and dma control. address phase state machine the address phase state ma chine is responsible for monitoring the pci bus and determining if a pci transaction is targeting cor epci. when a hit is detected, the dp_start/dp_start64 signals are activated, setting off the dataphase machine and backend logic. the address phase state machine also determines the cycle type and provides this in formation on the rd_cyc, wr_cyc, bar0_mem_cyc, bar1_cyc, and config_cyc outputs. dataphase state machine the dataphase state mach ine is responsible for controlling the pci output si gnals and coordinating the data transfers with the backend logic. when operating as a target, the pci output s are trdyn, devseln, and stopn. when operating as a master, irdyn is the primary pci output. data transfers to the backend are coordinated using the signals rd_be_rdy, rd_be_now, wr_be_rdy, and wr_be_now. the two "be_rdy" inputs indicate that the backend is ready to transmit or receive data. the "be_now" signals are synchronous data strobes and indicate that a data transfer will occur on the next rising edge of the clock. the dataphase state machine also drives the dp_d one output active at the end of the pci transfer. datapath the datapath module provides the steering and registers for the data between the pci bus and the backend. additionally, the datapath contains the address counters and increments the value af ter each data transaction. parity the parity block generates and checks parity on the pci bus. configuration the configuration block contains the configuration register file for the target controller. these registers include the id, status, cont rol, and the base address registers. the core implemen ts a single function type 0 configuration space. data transactions corepci is designed to be fully compliant for all transfer types, including both single dword and burst transactions. burst transfer s can operate with either zero, one, or more wait st ates. normally, corepci will burst data with zero wait states; however, for slow response peripherals, corepci can insert wait states under the control of the backend. during target operation, wait st ates are inserted by driving trdyn high. during master operation, corepci drives irdyn high to insert wait states. i/o signal descriptions the pci and backend signals for corepci are defined in table 5 on page 8 and table 6 on page 9 . for the purposes of this data sheet, the following signal type definitions are used: input: standard input-only signal. output: standard active driver that drives continuously. tristate output: standard active driver that can be tristated. bidirectional (referred to as t/s in the pci specification): a combin ation input and t/s output pin. sustained tristate ( s/t/s in the pci specification): a term used to describe either bidirectional or t/s output pins. the sts term indicates that the signal should always be driven to a logic '1' before the pin is tristated. open drain: drive to '0' only output. a pull-up is required to sustain the high-impedance state to a logic '1' and is provided by the pci backplane.
corepci v5.41 v4.0 7 for a complete list of signal descriptions, refer to table 5 on page 8 and table 6 on page 9 . figure 2 corepci block diagram irdyn stopn devseln trdyn serrn idsel ad par cbe perrn intan framen reqn gntn clk rstn pci bus back-end interface be_req be_gnt dp_start dp_done mem_add[23:0] rd_cyc wr_cyc bar0_mem_cyc bar1_cyc config_cyc be_rd_rdy rd_be_now be_wr_rdy wr_be_now[3:0] ext_intn dp_start64 rd_be_now64 wr_be_now64[3:0] error clk_out dma_gnt stall_master mem_dout mem_din mem_den error busy ext_intn cs_controln rd_controln wr_controln master_be master_be64 busy_master address phase state machine configuration dma controller and register file datapa th parity block dataphase state machine
corepci v5.41 8 v4.0 table 5 corepci interface signals name * type description clk input 33 mhz or 66 mhz clock input for the pci core rstn input active low asynchronous reset ad bidirectional multiplexed 32-bit or 64-bit address and data bus. valid address is indicated by framen assertion. cbe bidirectional bus command and byte enable information. during the address phase, the lower 4 bits define the bus command. during the dataphase, they define the byte enables. this bus is 4 bits for 32- bit pci systems and 8 bits in 64-bit systems. par bidirectional parity signal. parity is even across ad[31:0] and cbe[3:0]. par64 bidirectional upper parity signal. parity is even across ad[63:32] and cbe[7:4]. this signal is not required for 32-bit pci systems. framen bidirectional (sts) active low signal indicating the beg inning and duration of an access. while framen is asserted, data transfers continue. req64n bidirectional (sts) active low signal with the same ti ming as framen indicating that the master requests a data transfer over the full 64-bit bus. this signa l is not required for 32-bit pci systems. irdyn bidirectional (sts) active low signal indicating that th e bus master is ready to complete the current dataphase transaction. trdyn bidirectional (sts) active low signal indicating that the target is ready to complete the current dataphase transaction. stopn bidirectional (sts) active low signal from the target requesting termination of the current transaction. idsel input active high target select used during configuration read and write transactions. devseln bidirectional (sts) active low output from the target indicating that it is the target of the current access. ack64n bidirectional (sts) active low output from the target in dicating that it is capable of transferring data on the full 64-bit pci bus. this signal is driven in response to the req64n signal and has the same timing as devseln. this signal is not required in 32-bit pci systems. reqn output active low output used to request bus ownership. this signal is asserted by the pci master controller whenever master/dma mode is enabled. gntn input active low input from the system arbiter indicating that the core may claim bus ownership. perrn bidirectional (sts) active low parity error signal serrn open drain active low system error signal. this signal reports pci address parity errors. intan open drain active low interrupt request note: *active low signals are designated with a trailing lower-case n.
corepci v5.41 v4.0 9 table 6 corepci backend interface signal name 1,2 type description clk_out output clock output. the core uses an internal clock buffer, this is buffered version of the clock and should be used for clocking any other logic in the fpga that is clocked by the pci clock. bar0_mem_cyc output active high signal indicating a transac tion to the memory space defined in the base address register zero (bar0) located at 10h in configuration header space. bar1_cyc output active high signal indicating a transaction to the optional memory or i/o space defined in base address register one (bar1) located at 14h in configuration header space. config_cyc output active high signal indicating a transaction to configuration space. rd_cyc output active high signal indicating a read tran saction from the backend. wr_cyc output active high signal indicating a write transaction to the backend. mem_din input dword aligned 32- or 64-bit databus input mem_dout output dword aligned 32- or 64-bit databus output mem_data_den output active high data enable for mem_dout, lower 32-bit. this is intended as an output enable if mem_din and mem_dout are connected to bi-directional pads. mem_data_den64 output active high data enable for mem_dout , upper 32-bit. this is intended as an output enable if mem_din and mem_dout are connected to bi-directional pads. mem_add[n:0] 3 output dword aligned memory address bus where n is defined by the variable maddr_width. since the pci address is byte aligned, a 2-bit shift of the address is performed and pci address bits 0 and 1 are discarded. for example, a 1 mbyte memory requires 20 address bits to uniquely address each byte or 18 address bits to uniquely address each dword. a pci address of 'ccccc'h would translate to '33333'h on the backend. for writes, individual bytes are qualified with the 4-bit wr_be_now bus. al l reads are assumed to be full dwords. dp_start dp_start64 output dp_start is an active high pulse indicating that a pci transaction to the backend is beginning. if the transfer is 64-bit, then dp_start64 will be asserted at the same time as dp_start. dp_done output active high pulse indicating that a suc cessful pci transaction to the backend has finished. rd_be_now rd_be_now64 output active high synchronized read strobe. when active high, these signals indicate that the pci controller will read data on the mem_data bus on the next rising clock edge. these signals are active whenever both the backend (as ind icated by rd_be_rdy) and the pci bus (as indicated by irdyn) are ready to transmit data. the rd_be_now indicates a write to the lower 32 bits of data and the rd_be_no w64 indicates a read from th e upper 32 bits of data. function of these signals are impacted by the pipe_full_cnt bus ( figure 15 ). rd_be_rdy input active high signal indicating that the backend is ready to send data to the target interface. if the ready signal does not become active within the limits defined by the pci bus, then a disconnect without data will be initiated. notes: 1. active low signals are designated with a trailing lower-case n. 2. signals ending in "cyc" become valid as the same cycle dp_star t is active and will remain valid throughout the current cycle (until dp_done is asserted). 3. maddr_width is defined in table 22 on page 20 . 4. all inputs should be synchronous to the pci clock.
corepci v5.41 10 v4.0 wr_be_now[3:0] wr_be_now64[3:0] output active high synchronous write strobe. these signals indicate that the pci controller is providing valid write data on the mem_data bus. these signals are active whenever both the backend (as indicated by wr_be_rdy) and the pci bus (as indicated by irdyn) are ready to transmit data. the wr_be_now indicates a write from the lower 32 bits of data and the wr_be_now64 indicates a write from the upper 32 bits of data. for wr_be_now, each bit represents a byte enable with bit 0 corresponding to the least significant byte (byte 0) on the mem_data bus. similarly, for wr_be_now64, each bit represents a byte enable with bit 0 corresponding to byte 4 on the mem_data bus. function of these signals are impacted by the pipe_full_cnt bus ( figure 15 ). wr_be_rdy input active high signal indicating that the backend is ready to receive data from the target interface. if the ready signal does not become acti ve within the time limits defined by the pci bus, then a disconnect without data will be initiated. pipe_full_cnt[2:0] input normally, the address on mem_addre ss and the data on mem_data are coincident. in some backends, like synchronous srams, the data lags the address by one or more cycles. the pipe_full_cnt bus feeds a latency timer in the pci controller to help in these cases. when the pipe_full_cnt is non-zero, the pci controller will increment the address, the number of counts defined and will not expect data un til the count expires. the rd_be_now and wr_be_now signals need to be ignored during the time-out. for example, if pipe_full_cnt is set to '010', then the *_now signals should be ignored during the first two cycles they are active, while the address is initially incremented. be_req input a request from the backend to the pci cont roller to take control of the backend. this signal is active high, and should be synchronous to the pci clock. be_gnt output a grant from the pci controller giving control to the backend. when the be_gnt signal is active and a transaction to the pci target controller occurs, the pci controller will respond with a retry cycle. if a cycle is in progress when the be_req is asserted, the be_gnt will not assert until completion of the current pci cycle. if th e backend must take control during a cycle, then the ready signals can be de-asserted, causing a pci time-out and resulting disconnect. dma_gnt output indicates that the internal dma controll er has control of the back-end core interface. busy_master input when high dma cycles will not be started. if a dma-cycle is in progress and this signal goes high the dma cycle will be stopped within two data transfers, i.e. up to two more data cycles may occur when the signal goes high. stall_master input if high when corepci starts a dma cycle on the backend, it will assert dp_start, but hold off asserting frame and starting th e cycle on the pci bus until stall_master is deasserted (low) signifying that the back end's data is now ready. this can be used to support backends th at take several cycles to become ready. note that gnt can be removed at anytime while the core is wait ing for the backend data, which will cause the core to abort the cycle. error input active high signal that will force the pci c ontroller to terminate the current transfer with a target abort cycle. the signal affects the target function only, it is ignored during master operation. table 6 corepci backend interface signal (continued) name 1,2 type description notes: 1. active low signals are designated with a trailing lower-case n. 2. signals ending in "cyc" become valid as the same cycle dp_star t is active and will remain valid throughout the current cycle (until dp_done is asserted). 3. maddr_width is defined in table 22 on page 20 . 4. all inputs should be synchronous to the pci clock.
corepci v5.41 v4.0 11 busy input active high signal indicating that the backend controller cannot complete the current transfer. when busy is active at the beginning of a transf er, the target controller will perform a retry cycle. if busy is activated after some data has been transferred, the target controller will perform a disconnect cycle, either with or without data. th e signal affects the target function only, it is ignored during master operations. ext_intn input active low interrupt from the backend. when pci interrupts are enabled, this should cause an intan signal to be asserted. cs_controln input active low chip select to the dma registers (master and target+master functions). rd_controln input active low synchronous read enable for the dma registers (master and target+master functions only). wr_controln input active low synchronous write enable for the dma registers (master and target+master functions only). control_add[1:0] input two-bit address used to address the dma registers from the backend (master and target+master functions only). master_be[3:0] input active low-byte enable inputs used du ring master transfer to drive the lower cbe lines. master_be64[3:0] input active low-byte enable inputs used during master transfer to drive the upper cbe lines table 6 corepci backend interface signal (continued) name 1,2 type description notes: 1. active low signals are designated with a trailing lower-case n. 2. signals ending in "cyc" become valid as the same cycle dp_star t is active and will remain valid throughout the current cycle (until dp_done is asserted). 3. maddr_width is defined in table 22 on page 20 . 4. all inputs should be synchronous to the pci clock.
corepci v5.41 12 v4.0 corepci target function corepci target function acts like a slave on the pci bus. the target controller monito rs the bus and checks for hits to either configuration space or to th e address space defined in its base address registers (bars). when a hit is detected, the target controll er notifies the backend and then acts to control the flow of data between the pci bus and the backend. supported target commands table 7 on page 12 lists the pci commands supported in the current corepci target im plementation. if required, i/o support, and thus i/o co mmands, can be eliminated from the design by setting the appropriate customization options. i/o read (0010) and write (0011) the i/o read command is used to read data mapped into i/o address space. corepci w ill not check to verify the consistency of the address and byte enables. this and any additional error checking is left for implementation by the user. the i/o write comm and is used to write data mapped into i/o address space. in this case, the write is qualified by the byte enables. the default i/o space size is 256 bytes. memory read (0110) and write (0111) the memory read and write commands are used to read data in memory-mapped address space. the baseline memory core supports 4 megabytes for the 32-bit core and 8 megabytes for the 64-bit core, which can be located anywhere in 32-bit address space. the memory size may be set to any value using the maddr_width customization constant. configuration read ( 1010) and write (1011) the configuration read comm and is used to read the configuration space of each device. the configuration write command is employed to write information into the configuration spac e. the device is selected if its idsel signal is asserted and ad[1:0] are '00'b. additional address bits are defined as follows: ad[7:2] contain one of 64 dword addresses for the configuration registers. ad[10:8] indicate which device of a multi-function agent is addressed. the core does not support multi-function devices and these bits should be '000'b. ad[31:11] are "don?t cares." supported cycle types corepci target will perfor m either single dword or burst transactions depending on the request from the system master. if the backend is unable to deliver data, the target will respond with either a pci retry or disconnect, either with or without data. if the system master requests a transfer that the backend is not able to perform, a target abort can be initiated by the backend. target configuration space the pci specification require s a 64-byte configuration space (header) to define vari ous attributes of the pci target, as shown in table 8 on page 13 . all registers shown in bold are implemented, including the two base address registers. none of the remaining registers are included in the baseline implementation and will return zeroes when read. in the target-only function, one additional configuration register, 48h, is used to define backend interrupt control and status. for other functions, this information is contained in the dma control register. table 7 supported pci target commands c/be[3:0] command type supported 0000 interrupt acknowledge no 0001 special cycle no 0010 i/o read yes 0011 i/o write yes 0100 reserved ? 0101 reserved ? 0110 memory read yes 0111 memory write yes 1000 reserved ? 1001 reserved ? 1010 configuration read yes 1011 configuration write yes 1100 memory read multiple yes 1101 dual address cycle no 1110 memory read line yes 1111 memory write and invalidate no
corepci v5.41 v4.0 13 read-only configuration registers the read-only registers listed in table 8 on page 13 have default values, but should be modified by the designer. see the pci specification for setting these values: vendor id device id revision id class code subsystem id subsystem vendor id the header type register is al so read-only, but should not be modified (pre-set to a co nstant value of '00h'). the capability pointer is includ ed when the hot_swap_en customization constant is set to '1'b. see table 13 on page 16 for more information. read/write configuration registers the following registers have at least one bit that is both read and write capable. for a complete description, refer to the appropriate table. "command register (04h)" ( table 9 on page 14 ) " status register (06h)" ( table 10 on page 14 ) "memory base address register bit definition (locations 10h or 14h)" ( table 11 on page 16 ) "i/o base address register bit definitions (location 14h only)" ( table 12 on page 16 ) "interrupt register (3ch)" ( table 14 on page 16 ) "interrupt control/stat us register (48h)" ( table 15 on page 16 ) "optional hot-swap register (80h)" ( table 16 on page 16 ) table 8 pci configuration header 31?24 23?16 15?8 7?0 address device id vendor id 00h status command 04h class code revision id 08h bist header type latency timer cache line size 0ch base address #0 (memory location for baseline target) 10h base address #1 (optional memory or i/o) 14h base address #2 (optional i/o for dma register mapping) 18h base address #3 1ch base address #4 20h base address #5 24h cardbus cis pointer 28h subsystem id subsystem vendor id 2ch expansion rom base address 30h reserved capabilities pointer 34h reserved 38h max_lat min_gnt interrupt pin interrupt line 3ch interrupt control/status register 48h hot-swap register (optional) 80h
corepci v5.41 14 v4.0 table 9 command register (04h) bit type description 0 rw i/o space a value of '0' disables the device?s response to i/o space addresses. set to '0' after reset. 1 rw memory space a value of '0' disables the device?s response to memory space addresses. set to '0' after reset. 2 rw bus master when set to a '1' this bit enables the macro to behave as a pci bus master. for target-only implementation, this bit is read-only and is set to '0'. 3 ro special cycles no response to special cycles. it is set to '0'. 4 ro memory write and invalidate enable memory write and invalidate no t supported. it is set to '0'. 5 ro vga palette snoop assumes non-vga peripheral. it is set to '0'. 6 rw parity error response when '0' the device ignores parity errors. when '1 ' normal parity checking is performed. set to '0' after reset. 7 ro wait cycle control no data-stepping supported. it is set to '0'. 8 rw serrn enable when '0' the serrn driver is disabled. it is set to '0' after reset. 9 ro fast back-to-back enable set to ' 0 ' . only fast back-to-back transact ions to same agent are allowed. 10 rw interrupt disable when set this prevents the core from asserting its intan output. this bit is set to '0' after reset. 15?11 ro reserved and set to all ' 0 ' s. note: rw = read and write ro = read only table 10 status register (06h) bit type description 2?0 ro reserved?set to ' 000 ' b. 3 ro interrupt status this bit reflects the status of the intan output. 4 ro capabilities list when the hot_swap_en customization constant is set to a '1', the bit is set to a '1'; otherwise, it is set to '0'. 5 ro 66 mhz capable should be set to '1' to indicate a 66 mhz target, or '0' to indicate a 33 mhz target. the value depends on the mhz_66 customization constant. note: the rw capability in the status register is restricted to clearing the bit by writing a '1' into the bit location.
corepci v5.41 v4.0 15 6 ro udf supported set to '0' ? no user definable features. 7 ro fast back-to-back capable set to '0' ? fast back-to-back to same agent only. 8 rw data parity error detected if the master controller detects a perrn, this bit is set to a '1'. this bit is read-only in target-only implementations and is set to '0'. 10?9 ro devseln timing set to '10' ? slow devseln response. 11 rw signaled target abort set to '0' at system reset. this bit is set to a '1' by internal logic whenever a target abort cycle is executed. 12 rw received target abort if the master controller detects a target abort, this bit is set to a '1'. this bit is read-only in target- only implementations and is set to '0'. 13 rw received master abort if the master controller performs a master abort, th is bit is set to a '1'. this bit is read-only in target-only implementations and is set to '0'. 14 rw signaled system error set to '0' at system reset. this bit is set to '1' by internal logic whenever the serrn signal is asserted by the target. 15 rw detected parity error set to '0' at system reset. this bit is set to '1' by internal logic whenever a parity error, address, or data is detected, regardless of the value of bit 6 in the command register. table 10 status register (06h) (continued) bit type description note: the rw capability in the status register is restricted to clearing the bit by writing a '1' into the bit location.
corepci v5.41 16 v4.0 table 11 memory base address register bit definition (locations 10h or 14h) bit type description 0 ro set to '0' to indicate memory space. 2?1 ro set to '00' to indic ate mapping into any 32-bit address space. 3 ro set to a '1' indicating prefetch allowed on reads. 23?4 ro indicates a 16 mb address space. it is set to all '0's. 31?24 rw programmable location for 16 mb address space. to determine a hit, these bits must be compared to pci address bits 31?24. note: the description for bit values 31?24 and 23?4 will vary depending on the actual memory size defined in the customization options. see "customization options" on page 19 for more information. table 12 i/o base address register bit definitions (location 14h only) bit type description 0 ro set to '1' to indicate i/o space. 1 ro reserved. it is set to '0'. 7?2 ro 256-byte i/o space for this peripheral. it is set to all '0's. 31?8 rw programmable address for this peripheral?s i/o space. to determine a hit, these bits must be compared to pci address bits 31?8. note: the description for bit values 31?8 and 7?2 will vary depending on the actual memory size defined in the customization options. see "customization options" on page 19 for more information. table 13 capabilities pointer (34h) bit type description 7?0 ro set to '10000000'b when the customization constant, hot_swap_en, is set to a '1'; otherwise, it is all zeroes. 31?8 rw reserved. it is set to '0'. note: this register is not required if hot-swap is not enabled. see "customization options" on page 19 for more information. table 14 interrupt register (3ch) bit type description 7?0 rw required read/write register. this register has no impact on internal logic. 15?8 ro set to '00000001'b to indicate intan. table 15 interrupt control/status register (48h) bit type description 7?0 ro reserved. it is set to all zeroes. 8 rw a '1' in this bit indicates an active external interrupt condition (assertion of ext_intn). the user can clear it by writing a '1' to the bit position. it is set to '0' after reset. 9 rw writing a '1' to this bit enables support for the external interrupt signal. writing a '0' to this bit disables external interrupt support. 31?10 ro reserved. it is set to '0'. table 16 optional hot-swap register (80h) bit type description 7?0 ro reserved. it is set to all zeroes. 8 ro reserved. it is set to '0'. 9 rw enum# signal mask. 10 ro reserved. it is set to '0'. 11 rw led on/off. when set to a '1', this bit is used to drive a blue led indicating that it is safe to extract the card. 13?12 ro reserved. it is set to '0'. 14 rw enum# insertion status. 15 rw enum# insertion status. 23?16 ro the next item located in the capabilities list. set to '0' in the baseline core. 31?24 ro set to '06'h to indicate hot-swap capability.
corepci v5.41 v4.0 17 corepci master function the master function in corepci is designed to perform the following: arbitrate for the pci bus initiate an access by asserting framen and providing the address and command pass dataflow control to the target controller end the transfer when the dma count has been exhausted by de-asserting framen supported master commands corepci master controller is capable of performing configuration, i/o, memory, and interrupt acknowledge cycles. data transfers can be up to 4kb. however, configuration and i/o comman ds are typically limited to a single dword. the master controller will attempt to complete the transfer in a single burst unless the maximum burst length bits are set in the control register. if the addressed target is unable to complete the transfer and performs a retry or disconnect, the master control will restart the transfer and continue from the last known good transfer. if a target does not res pond (no devseln asserted) or responds with target abort cycle, the master controller will abort the current transaction and report it as an error in the control register. the supported corepci master commands are listed in table 17 . master registers there are three registers used to control the function of corepci master. the first regist er is the 32-bit pci address register. the second register is the 32-bit ram or backend address register. thes e two registers provide the source/destination addressing for all data transfers. a 32- bit control register defines the type, length, and status of a master transfer. these registers are cleared on reset. they are defined in detail in table 18 and table 19 on this page, and table 20 on page 18 . table 17 supported corepci master commands cbe[3:0] command type 0000 interrupt acknowledge cycle 0010 i/o read 0011 i/o write 0110 memory read 0111 memory write 1010 configuration read 1011 configuration write table 18 pci start address bit type description 1?0 ro set to '00'b. pci transfers must be on a dword boundary. 31?2 rw pci start address this location will increment during the dma transfer when the dma_cnt_en customization constant is set to a '1'. otherwise at the end of a transfer, this register value will hold the initial starting address. table 17 supported corepci master commands cbe[3:0] command type table 19 ram start address bit type description 1?0 ro set to '00'b. pci transfers must be on a dword boundary. 23?2 rw ram start address this location will increment during the dma transfer when the dma_cnt_en customization constant is set to a '1'. otherwise at the end of a transfer, this register value will hold the initial starting address. 31?24 ro set to all zeros. note: the description for bit value s 31?24 and 23?2 will vary depending on the actual memory size defined in the customization option s. see "customization options" on page 19 for more information. for this ca se, maddr_width is set to 24.
corepci v5.41 18 v4.0 table 20 dma control register bit type description 0?1 rw dma error 00 ? no error 01 ? master abort 10 ? parity error 11 ? target abort 2rodma done a '1' indicates that the dma transfer is done. writing a '0' clears this bit. 3 rw dma direction a '1' indicates a read from pci and a write to ram. a '0' indicates a read from ram and a write to pci. 4rwdma request writing a '1' will initiate a dma transfer and the bit will remain set until the dma transfer completes or an error occurs (master abort or target abort). 5 rw dma enable this bit must be set to '1' to enable any dma transfers. 6 rw dma interrupt status a '1' in this bit indicates the dma cycle has comple ted and the interrupt is active. the user clears this bit by writing a '1' to this bit. set to '0' after reset. 7 rw dma interrupt enable writing a '1' to this bit enables the dma complete interrupt. set to '0' after reset. 8 rw external interrupt status a '1' in this bit indicates an acti ve external interrupt condition (assertion of ext_intn). the user clears it by writing a '1' to this bit position. set to '0' after reset. 9 rw external interrupt enable writing a '1' to this bit enables the external interrupt signal. writing a '0' to this bit disables external interrupt support. 10 rw memory transfer width writing a '1' to this bit enables a 64-bit memory transaction. for 32-bit corepci cores, this bit is read-only and is set to a '0'. 15?14 ro reserved (set to '00'b). 13?11 rw sets the type of pci cycle performed: 000 ? memory cycle 001 ? configuration cycle 010 ? interrupt acknowledge 100 ? i/o cycle other encodings should not be used. 27?16 rw* dma transfer length number of bytes to be transferred. bits 16 and 17 are set to '0' since dma transactions must be on dword boundaries. during a dma transfer, this location will decrement indicating the number of bytes remaining. to transfer 1024 dwords, this location sho uld be set to all zeros.
corepci v5.41 v4.0 19 master register access there are three different ways that the master registers can be accessed. the addr ess locations for the dma registers are listed in table 21 . for master functions, the registers are only accessible from the pci bus and can be either i/o mapped or config uration mapped. for the i/o mapping, the core uses base address register #2 to assign a 256-byte memory space. the registers are then located at addresses 40h, 44h, and 48h. to map these registers into i/o, the dma _in_io customization constant must be set to a '1'. when this constant is set to a '0', the registers are configuration mapped again at locations 40h, 44h, and 48h. for master and target+master functions, these registers are accessed via the backe nd. a two-bit address bus, control_add[1:0], is provided along with chip select, read, and write signals. customization options corepci has a variety of options for user customization. a special package defining a list of variables that allow the user to optimize the core fo r a particular application is included with the source design files. all of the constants are applicable to the ta rget+dma function. for target+master functions, the dma_in_io constant is not required. for target functions, the dma_in_io and dma_cnt_en constants are not required. for master functions, only the bit64 and the maddr_width constants are used. table 22 lists the variables and their descriptions. configuration register constants to set the read-only register s in the configuration space, a variety of constants are defined. the constants support the definitions of the device id register, vendor id register, class code registers, revision id register, subsystem id, and the subsystem vendor id. other options in addition to the read-only configuration definitions, corepci offers a variety of customization options summarized as follows: 32-bit or 64-bit data size (bit64) 33 or 66 mhz operation (mhz_66) bar0 address size (maddr_width) optional bar1 definitions (bar1_enable, bar1_io_memory, bar1_addr_width, and bar1_prefetch option to have the dma registers mapped into i/o space (dma_in_io) for target+dma functions 28 ro reserved (set to '0'). 31?29 rw maximum burst length when set to '000'b, the master controller will attempt to complete the requested transfer in a single burst. when set to non-zero, the master will automatically break up long bursts and limit burst transfer lengths to 2**(n-1) where n is the de cimal value of bits 31:29. therefore, maximum transfer lengths can be limited to 1, 2, 4, 8, 16 , 32 or 64 dataphases. for example, if the maximum burst length is set to '101'b (16 transfers), then a 1024 dword transfer count would be broken up into 64 individual pci accesses. table 20 dma control register (continued) bit type description table 21 address locations for the dma registers register name configuration addr ess i/o address backend address pci address 40h 40h 00b ram address 44h 44h 01b dma control register 48h 48h 10b
corepci v5.41 20 v4.0 table 22 corepci customization constants constant type description user_device_id 1 binary device id constant user_vendor_id 1 binary vendor id constant user_revision_id 1 binary revision id constant user_base_class 1 binary base class constant user_sub_class 1 binary sub class constant user_program_if 1 binary base class interface constant user_subsystem_id 1 binary subsystem id constant user_subvendor_id 1 binary subsystem vendor id constant bit_64 binary defines whether the core should behave as a 32-bit ('0') or a 64-bit ('1') pci controller. mhz_66 1 binary defines the value of bit 5 in the status register. a '1' indicates the core is capable of running at 66 mhz. dma_cnt_en 1 binary when this constant is set to a '1', counti ng is enabled for the pci start address, ram start address, and transfer length registers in the dma control module. for master applications with very short bursts, this constant can be set to a '0'. dma_in_io 2 binary when this constant is set to a '0', the dma registers are mapped into configuration space at addresses 40h, 44h, and 48h. if the constant is set to a '1', then the dma registers are mapped into i/o space defined by base address register 2. the i/o port addresses for the dma registers are at 40h, 44h, and 48h. maddr_width integer defines memory space size for base a ddress register zero. allowable range is 8-31 where 8 represents 256 bytes and 24 represents 16 mbytes of memory space. for master-only functions, this constant defines the size of the master?s backend memory. bar1_enable 3 binary this constant enables ('1') base address regist er 1 (14h) to be either a memory or an i/o space. bar1_io_memory 3 binary defines the type of base address register one. a memory is defined by a '1' and an i/o is defined by a '0'. bar1_addr_width 3 integer defines memory or i/o space size for base address register one. an integer setting of n in this field corresponds to 2**n bytes. allo wable range for memory is 8-31 where 8 represents 256 bytes and 24 represents 16 mbytes of memory space. valid range for i/o is 2 to 8. bar1_prefetch 3 binary when bar1 is a memory bar, this constant defines the value of bit 3 (prefetchable bit) in the base address register. hot_swap_en 3 binary when hot_swap_en is set to a '1', this cons tant will set bit 4 in th e control register to a '1', will set the capability pointer to be 80h, and will implement the hot-swap extended capability register at configuration address 80h. notes: 1. not applicable in target-only core. 2. only applicable in target+dma core. 3. not applicable in master-only core.
corepci v5.41 v4.0 21 enable_bar_overflow binary when enable_bar_overflow is set the core will force a disconnect at the address boundary. when false the core will wrap around internally, this violates the pci specification. when '1', the core will be slig htly bigger and may cause disconnects when the last four memory locations are accessed. to avoid the extra logic and disconnects this generic may be set to '0'. export_clock_out binary when export_clock_out is set the core will provide a clk_out port that contains the internal buffered pci clock. this should be used for clocking other circuitry within the fpga. table 22 corepci customization constants (continued) constant type description notes: 1. not applicable in target-only core. 2. only applicable in target+dma core. 3. not applicable in master-only core.
corepci v5.41 22 v4.0 system timing to meet 33 mhz pci timing specifications, only standard speed devices from the a54s x, a54sx-a, ax, a500k, and the apa families are required. to meet 66 mhz pci timing requirements, the "?3" speed grade parts from the sx-a family or "?1" parts from the ax family must be used. pci target transactions corepci supports both 32-bit and 64-bit data transfers. configuration and i/o cycl es are limited to 32-bit transfers; however, memory transactions can be either. most of the waveforms are shown for 32-bit transfers. to move from 32-bit to 64-bit, a set of 64-bit control signals are supplied by both the back end as well as the pci bus. for 64-bit memory transfers, these signals mirror their 32-bit counterparts with identical function and timing and are as follows: req64n is the same as framen ack64n is the same as devseln par64 is the same as par dp_start64 is the same as dp_start rd_be_now64 is the same as rd_be_now wr_be_now64 is the same as wr_be_now in addition to these control signals, the ad and mem_data buses are 64-bit ra ther than 32-bit. also, the cbe bus is expanded from 4 bits to 8 bits. a complete example of a 64-bit read and write is illustrated in figure 9 on page 26 and figure 10 on page 27 . configuration cycles configuration read and write cycles are used to define and determine the status of the target?s internal configuration registers. configuration cycles are the only type of transactions that use the idsel signal. register selection is defined by the contents of the address (bits 7 down to 2). a configurat ion write is shown in figure 5 and a configuration read is shown in figure 6 on page 23 . corepci will also support burst transactions to configuration space if required. memory / i/o cycles zero-wait-state burst transactions zero-wait-state bursting enab les transfer of a dword (32-bit pci) or two dwords (64-bit pci) for every clock cycle. all cycles are initiated with dp_start/dp_start64 indicating a hit to the target. the backend should then look at the bar0_mem_cyc and bar1_cyc to determine which space is be ing addressed. the rd_cyc and wr_cyc signals define the direction of the transfer. all of the *_cyc signals become valid during the dp_start pulse cycle and will remain in the this state until the next dp_start occurs. if a dp_start64 is coincident with a dp_start, then the transaction is expected to be 64 bits wide. for pci writes, the backend i ndicates that it is prepared to receive data by setting the wr_be_rdy signal high. valid data to the backend is qualified by the wr_be_now bus. for pci read s, the backend indicates that it is prepared to pro vide read data by setting the rd_be_rdy signal. the pci controller will respond on a following cycle with a rd_be_now signal, which qualifies the read data. the data is then transferred to the pci bus on the following cy cle. in either the read or write case, the core will automatically increment the address. figure 3 input timing for pci signals figure 4 output timing for pci signals t_h inputs valid clk t_su clk tristate output t_val t_off t_on output delay
corepci v5.41 v4.0 23 notes: 1. if the target?s idsel is asserted when framen is asserted a nd the command bus is '1011', then a configuration write cycle is indicated. 2. the target claims the bus by asserting devseln in cycle 4. 3. data is registered into the device on the rising edge of cycle 5. 4. the single dword transfer completes when trdyn is asserted in cycle 5 and de-asserted in cycle 6. figure 5 configuration write cycle notes: 1. if the target?s idsel is asserted when framen is asserted and the command bus is '1010', then a configuration read cycle is indicated. 2. the target claims the bus by asserting devseln in cycle 4. 3. during cycle 7, trdyn is asserted and valid data is driven onto the pci bus. 4. the single dword transfer completes when trdyn is de-asserted in cycle 8. figure 6 configuration read cycle 12 3 4 56 7 8 clk addr idsel 1011 paddr data0 pdata0 byte enables framen ad cbe irdyn trdyn devseln par stopn clk idsel framen ad cbe irdyn trdyn devseln par stopn 12 3 4 56 7 8 910 data0 pd0 byte enables 1010 addr paddr
corepci v5.41 24 v4.0 in the case of a pci read, th e backend must prefetch the memory data in order to ensure continuity on long bursts. if prefetching causes a problem, for example in a fifo, the backend logic should shadow the last two data transactions. 32-bit zero-wait-state burst transfers are shown in figure 7 on page 24 and figure 8 on page 25 . 64-bit zero-wait-state burst transfers are shown in figure 9 on page 26 and figure 10 on page 27 . notes: 1. when framen is asserted and the command bus is '0111,' then a write to memory space is indicated. 2. the target will compare the address to the progra mmed space set in the memory base address register. 3. if an address hit occurs, then the target asserts dp_start in cycle 3 and claims the pci bus by asserting devseln in cycle 4. 4. data transfer to the backend begins on the rising edge of cycl e 7 and continues for each subsequent cycle until the pci bus e nds the data transfer. 5. the address will increment each cycle following an active rd_be_now. 6. the pci transaction completes when trdyn is de-asserted in cycle 9 and completes on the backend in cycle 10. 7. for this case, the pipe_full_cnt is set to "000" (see "backend latency control" on page 31 for more information). figure 7 32-bit burst write with zero wait states clk addr 0111 paddr data0 pdata0 data1 data2 data3 pd1 pd2 pd3 byte enables add1 add2 add3 data1 data2 data3 data0 add0 12 3 4 56 7 8 910 11 12 framen ad cbe irdyn trdyn devseln par stopn mem_address mem_data dp_done barn_cyc wr_be_rdy wr_be_now wr_cyc dp_start
corepci v5.41 v4.0 25 notes: 1. when framen is asserted and th e command bus is '0110', then a read from memory space is indicated. 2. the target will compare the address to the progra mmed space set in the memory base address register. 3. if an address hit occurs, then the target asserts dp_start in cycle 3 and claims the pci bus by asserting devseln in cycle 4. 4. data transfer from the backend begins on the rising edge of cycl e 7 and continues for each subsequent cycle until the pci bus ends the data transfer. the backend prefetches three dwords during zero-wait-state bursts. 5. the address will increment each cycle following an active rd_be_now. 6. the pci transaction completes when trdyn is de-asserted in cycle 10. 7. for this case, the pipe_full_cnt is set to "000" (see "backend latency control" on page 31 for more information). figure 8 32-bit burst read with zero wait states clk addr 0110 paddr data1 data2 data3 pd1 pd2 pd3 add2 add3 add4 data2 data3 data4 data1 12 3 4 56 7 8 910 11 12 data0 pd0 add1 data0 byte enables framen ad cbe irdyn trdyn devseln par stopn mem_address mem_data dp_done dp_start rd_be_rdy rd_be_now add0 add5 data5 barn_cyc rd_cyc
corepci v5.41 26 v4.0 notes: 1. when framen and req64n is asserted and the command bus is '0111', then a 64-bit write to memory space is indicated. 2. the target will compare the address to the progra mmed space set in the memory base address register. 3. if an address hit occurs, then the target asserts dp_start and dp_start64 in cycle 3 and claims the pci bus by asserting devs eln and ack64n in cycle 4. 4. data transfer to the backend begins on the rising edge of cycl e 7 and continues for each subsequent cycle until the pci bus e nds the data transfer. 5. for 64-bit transfer, the mem_address will increment by 2 for each cycle. 6. the pci transaction completes when trdyn is de-asserted in cycle 10. 7. for this case, the pipe_full_cnt is set to '000' (see "backend latency control" on page 31 for more information). 8. see "backend latency control" on page 31 for rd_cyc and barn_cyc timing. figure 9 64-bit burst write with zero wait states clk zero 0111 paddr data1 pdata1 data3 data5 data7 pd3 pd5 pd7 byte enables add2 add4 add6 data3 data5 data7 data1 add0 12 3 4 56 7 8 910 11 12 framen ad[63:32] cbe irdyn trdyn devseln par stopn mem_address mem_data[63:32] dp_done dp_start wr_be_rdy wr_be_now req64n zero pdata0 pd2 pd4 pd6 par64 ack64n dp_start64 wr_be_now64 1111 1111 0000 0000 0000 0000 addr data0 data2 data4 data6 ad[31:0] data2 data4 data6 data0 mem_data[31:0]
corepci v5.41 v4.0 27 notes: 1. when framen and req64n is asserted and the command bus is ' 0110', then a 64-bit read from memory space is indicated. 2. the target will compare the address to the progra mmed space set in the memory base address register. 3. if an address hit occurs, then the target asserts dp_start and dp_start64 in cycle 3 and claims the pci bus by asserting devs eln and ack64n in cycle 4. 4. data transfer from the backend begins on the rising edge of cycl e 7 and continues for each subsequent cycle until the pci bus ends the data transfer. the backend prefetches th ree dwords during zero-wait- state bursts. 5. for 64-bit transfers, the mem_address will increment by 2 each cycle. 6. the pci transaction completes when trdyn is de-asserted in cycle 10. 7. for this case, the pipe_full_cnt is set to '000' (see "backend latency control" on page 31 for more information). see "backend latency control" on page 31 for rd_cyc and barn_cyc timing. figure 10 64-bit burst read with zero wait states clk zero 0110 paddr data3 data5 data7 pd2 pd4 pd6 add4 add6 add8 data5 data7 data9 data3 12 3 4 56 7 8 910 11 12 data1 pd0 add2 data1 byte enables framen ad[63:32] cbe irdyn trdyn devseln par stopn mem_address mem_data[63:32] dp_done dp_start rd_be_rdy rd_be_now req64n zero pd3 pd5 pd7 pd1 par64 addr data2 data4 data6 data0 ad[31:0] ack64n dp_start64 rd_be_now64 data4 data6 data8 data2 data0 mem_data[31:0] add0 adda datab dataa
corepci v5.41 28 v4.0 paced transactions backend throttle transfers provide a handshake mechanism for supporting slow response devices. the backend transactions are paced using the rd_be_rdy and wr_be_rdy signals. thes e signals can be used to pace either single dword or burst transactions. figure 11 and figure 12 on page 29 illustrate this mechanism for a backend that requires three cycles to respond to a read or write command from the pci bus. notes: 1. the wr_be_rdy can be asserted two cycles before the backend is ready to receive data. 2. the wr_be_rdy signal is asserted on cycle 4 (cycle 7), causing th e assertion of trydyn on cycle 5 (cycle 8), completing the p ci write cycle. one cycle later, the data is available on the backend and is qu alified by the wr_be_now[3:0] bus. 3. the wr_be_now[3:0] should not be assumed to happen at this time (cycle 6 or cycle 9) because it is also dependent on the stat e of irdyn. 4. see figure 7 on page 24 for wr_cyc and barn_cyc timing. figure 11 write using backend throttling clk addr 0111 paddr framen ad[31:0] cbe[3:0] irdyn trdyn devseln par stopn data0 pdata0 mem_address[23:2] mem_data[31:0] dp_done dp_start wr_be_rdy wr_be_now byte enables data1 data0 add0 12 3 4 56 7 8 910 11 12 pd1 add1 data1
corepci v5.41 v4.0 29 paused transactions during long bursts, either the backend controller or the pci master may insert wait states to accommodate some functional requirement. th e pci master inserts wait states by de-asserting the ir dyn signal. the wait state is indicated to the backend by de-assertion of the wr_be_now bus or the rd_be_now signal. the backend can insert wait st ates by de-assertion of the *_be_rdy signals. these signals cause the target controller to de-assert trdyn and insert wait states on the pci bus. for writes, the backend must be prepared to accept up to two dwords of data prior to data transfer termination. for reads, the backend must be prepared to transmit one dword of data prior to data transfer termination. paused tran sactions are shown in figure 13 and figure 14 on page 31 . notes: 1. the rd_be_rdy can be asser ted one cycle before the backe nd is ready to transmit data. 2. the rd_be_rdy signal is asserted on cycle 5 (cycle 8) and wi ll initiate assertion of rd_be_now latching the data into the con troller. the data transfer will complete when trdyn is asserte d on the following cycle 7 (cycle 10). 3. the rd_be_now should not be assumed to happen at this time (cycle 6 or 9) because it is also dependent on the state of irdyn. 4. see figure 8 on page 25 for rd_cyc and barn_cyc timing. figure 12 read using backend throttling clk addr 0110 paddr framen ad[31:0] cbe[3:0] irdyn trdyn devseln par stopn mem_address[23:2] mem_data[31:0] dp_done dp_start rd_be_rdy rd_be_now data0 pd0 data0 12 3 4 56 7 8 910 11 12 add0 data1 add1 data1 pd0 14 13 byte enables add2
corepci v5.41 30 v4.0 notes: 1. in the example, the flow of data is interrupted from the pci master de-assertion of irdyn in cy cle 3. the pci master inserts two wait states. this state of the pci bus is d efined to the backend by de-asserting the wr_be_now[3 :0] bus one cycle later. 2. the backend can also interrupt the flow of data by de-asserting the wr_be_rdy signal. one cycle later, trdyn is de-asserted, halting the flow of data on the pci bus. the backend must accept two dwords of data following de-asse rtion of the wr_be_rdy signal. figure 13 pci write illustrating both irdyn and trdyn de-assertion clk framen ad[31:0] cbe[3:0] irdyn trdyn devseln par stopn mem_address[23:2] mem_data[31:0] dp_done dp_start wr_be_rdy wr_be_now data2 data3 pd2 pd3 add1 add2 data1 data2 13 14 15 16 56 7 8 910 11 12 12 3 4 pd1 data4 pd4 data6 data7 data8 data11 pd6 pd7 pd8 pd9 add3 data3 add4 data4 data5 pd5 data9 byte enables data10 data12 pd10 pd11 data5 add5 add6 add7 add8 add9 data6 data7 data8 data9 add10 add11 data11 data10
corepci v5.41 v4.0 31 backend latency control some backends require the address to be available at least one cycle prior to data being valid. this is true for most synchronous backends. in order to support this need, corepci provides the pipe_full_cnt control bus to the backend. this bus can be used to define the relative delay between address and data. when the pipe_full_cnt is set to '000', the address will be expected to be coincident with the data and the data should be valid whenever th e *now lines are asserted. when pipe_full_cnt is set to a non-zero value, then the operation of the bac kend is as follows: the backend asserts the *rdy signal. the *now signal will assert, and the address will begin incrementing. however, the data is not expected to be valid unt il n cycles after the value defined on the pipe_full_cnt bus. once the initial time-out occurs, valid data must be available whenever the *now signal is asserted. figure 15 is an example of this function for a read cycle with the pipe_full_cnt set to '001'. notes: 1. in the example, the pci master interrupts the flow of data by de-asserting the irdyn sign in cycl e 4. one cycle later, rd_be_ now signal becomes inactive indicating that the backend should stop supplying data. 2. the backend can also interrupt the flow of data by de-asserting the rd_be_rdy signal. the backen d should be prepared to provi de one additional dword of data to the pci bus prior to haltin g the data flow. one cycle after rd_be_rdy is de-asserted, the rd_be_now signal is driven inactive, which is then followed by the de-assertion of trdyn. figure 14 pci read illustrating both irdyn and trdyn de-assertion clk framen ad[31:0] cbe[3:0] irdyn trdyn devseln par stopn mem_address[23:2] mem_data[31:0] dp_done dp_start rd_be_rdy rd_be_now data2 data3 pd2 pd3 add3 add4 data3 data4 13 14 15 16 56 7 8 910 11 12 12 3 4 pd1 data4 data5 pd4 pd5 data6 data7 data8 data9 data10 data11 pd6 pd7 pd8 pd9 pd10 add5 data5 add6 data6 data7 data12 pd11 data8 data9 add7 add8 add9 add10 data10 add11 add12 add13 data11 data12 data13 byte enables
corepci v5.41 32 v4.0 target abort the backend may cause a target abort ( figure 16 ) by asserting the error input. the error input will cause a target abort, which is defined by the target simultaneously asserting the stopn signa l and de-asserting the devseln signal. figure 15 backend latency read transaction clk addr 0110 paddr data1 data2 pd1 pd2 add2 add3 add4 data2 data3 data4 data1 12 3 4 5 6 7 8 910 11 12 data0 pd0 add1 data0 byte enables framen ad cbe irdyn trdyn devseln par stopn mem_address mem_data dp_done dp_start rd_be_rdy rd_be_now add0 add5 data5 pipe_full_cnt 000 001 add6 notes: 1. during a pci cycle, the backend error signal indicates that a problem occurred on the backend such that the transfer cannot b e completed. 2. the target initiates a target abort by asserting sto pn and de-asserting devseln in the same cycle. 3. the master will begin cycle termination by de-asserting framen first, and then irdyn on a subsequent cycle. 4. the transaction completes when stopn is de-asserted in cycle 9. 5. the *_be_rdy signal should be de-asserted whenever the error signal is asserted. figure 16 target abort cycle clk addr 0111 paddr framen ad[31:0] cbe[3:0] irdyn trdyn devseln par stopn data0 pdata0 error 1 2 3 4 56 7 8 910 11 12 data3 pd3 byte enables data1 pd1 pd2 data2
corepci v5.41 v4.0 33 target retry and disconnect when the backend is busy or unable to provide the data requested, the target contro ller will respond with either a retry or a disconnect cycle. if the backend has arbitrated for control of the backend bus and the be_gnt signal is active, then the controller will respond with a retry cycle ( figure 17 ). the target indicates that it is unable to respond by asserting stopn and devseln simultaneously. during a regular pci transfer, the rd_be_rdy and wr_be_rdy indicate that data is available to be received from or transmitted to the backend. if, during a pci cycle, the backend becomes unable to read or write data, then the *_rd_rdy signals ar e de-asserted. after several cycles, a pci time-out will oc cur and the target controller will initiate a target disc onnect without data cycle ( figure 18 on page 34 ). notes: 1. if be_gnt or busy are asserted at the begin ning of a cycle, then a retry is initiated. 2. the target simultaneously asserts the stopn and devseln signals without asserting the trdyn signal. 3. the master will begin cycle termination by de-asserting framen first and then irdyn on a subsequent cycle. figure 17 target retry clk addr 0110 paddr framen ad[31:0] cbe[3:0] irdyn trdyn devseln par stopn 1 2 3 4 56 7 8 byte enables be_gnt
corepci v5.41 34 v4.0 backend arbitration when the backend needs to take control of the backend bus, it should arbitrate for control using the be_req and be_gnt handshake signals ( figure 19 on page 34 ). interrupt to initiate an interrupt, the backend needs to assert the ext_intn input ( figure 20 on page 35 ). two cycles later the pci intan interrupt signal will assert. notes: 1. during a normal pci transaction, the backend reaches a point wh ere it is unable to deliver data and de-asserts rd_be_rdy. 2. if the backend cannot deliver new data within 8 cycles, then it should assert the busy signal. 3. the target initiates a disconnect by asserting the stopn signal. 4. the master will begin cycle termination by de-asserting framen first, and then irdyn on a subsequent cycle. figure 18 target disconnect without data clk framen ad[31:0] cbe[3:0] irdyn trdyn devseln par stopn mem_address[23:2] mem_data[31:0] dp_done dp_start rd_be_rdy rd_be_now add5 add6 add7 data5 data6 data7 data4 data5 data6 data7 pd4 pd5 pd6 pd7 pd3 12 3 4 56 7 8 910 11 12 busy pd8 data8 add8 data8 add9 notes: 1. arbitration begins by the backend asserting the be_req signal. the target controller will grant control as soon as the pci co ntroller goes into an idle state. 2. the backend will maintain control as long as the be_req signal remains active. 3. to relinquish control, the backend will de-assert th e be_req and be_gnt will de-assert on the following cycle. figure 19 backend arbitration cycle clk be_req be_gnt
corepci v5.41 v4.0 35 pci master transactions to perform master transfers for master only, target+dma, and target+master functions, corepci controller has three configuration registers used to set addresses, transfer length, control, and check status of the transfer. a basic sequence of events for executing a dma or master transfer is as follows: 1. write the location of the desired pci address into the pci start address register. 2. write the location of the backend memory location into the ram start address register. 3. set the direction of the transfer using bit 3 of the dma control register. 4. define the transfer leng th using bits 27?16 in the dma control register. the length can be from a single dword up to 1,024 dwords. the transfer length value should be all zeros for 1,024 dwords. 5. initiate the transfer by setting the dma request, and enable bits 4 and 5 in the dma control register. 6. at completion, bit 1 in the dma control register is set to a ' 1'. pci dma read dma reads begin with arbitrat ion for control of the pci bus. the pci request and grant signals are used to arbitrate master access to the bus. once control is granted to the core, the core begins by asserting framen, the address on the ad bus, and the command ' 0110' on the cbe bus. a dma read fetches data from the pci bus and writes data to the backend memory. the core asserts irdyn and then waits for the addressed target to provide the data indicated by trdyn assertion. the transfer continues until the dma transfer length is reached. the waveforms shown in figure 21 on page 36 depict the action of the core when it operates as a dma master in a zero-wait- state read transfer. for dma transactions, either zero-wait-state transfers or paced transfers can be used. during dma transactions, these two transfer modes function identically, as they do in a target-only transaction. notes: 1. the ext_intn signal is sampled on the rising edge of each clock. 2. if the ext_intn signal is asserted and sampled in cycle 2, then the pci intan signal will be asserted in cycle 3. figure 20 interrupt 12 3 4 clk ext_intn intan
corepci v5.41 36 v4.0 pci dma write a dma write begins by the core requesting control of the bus. once the bus is gr anted (gntn asserted), the core will initiate the transf er by asserting framen. a dma write reads informat ion from ram and writes information onto the pci bus. the backend begins fetching data and when data is available, the datapath pipe fills and data flows onto the pci bus. at that point, irdyn is asserted and the burst transfer begins. the transfer is terminated once the dma transfer length is reached. figure 22 on page 37 shows the zero-wait-state burst write transfer. to control the master-only core, four backend signals have been added. the new signals are cs_controln, rd_controln, wr_control n and control_add(1:0). figure 25 and figure 26 on page 39 show how these signals are used to read and write the dma control registers, which in turn initiates pci cycles. notes: 1. once corepci is granted the pci bus, the core asserts dp_start and begins the process of enabling the bus to drive framen. 2. the pci address and command are valid at the same time that framen is driven low. 3. once framen is driven, if the backend is prepared to supply data, then irdyn is asserted on the following cycle. the core can store up to two dwords of data. if the target ha s not responded with a trdyn when the second dword is read , then the core will cease reading as indicated by the rd_be_now signal de-asserting. 4. the core then waits for the target to complete the transfer by asserting trdyn. 5. the transfer continues until ei ther the transfer coun t is exhausted or th e target disconnects. 6. cycle termination is initiated by driving framen high. 7. the number of clock cycles from dp_start to framen as sertion can be increased by asserting stall_master. figure 21 zero-wait-state master dma read (read from the pci bus) clk framen ad[31:0] c_be[3:0] irdyn trdyn devseln par stopn 13 14 15 16 56 7 8 910 11 12 12 3 4 mem_address[23:2] mem_data[31:0] wr_be_now[3:0] wr_be_rdy dp_start data0 data1 data2 data3 data0 data1 data2 data3 addr1 addr2 addr3 addr4 addr0 byte enables pd0 pd1 pd2 pd3 addr paddr cmd dp_done wr_cyc barn_cyc
corepci v5.41 v4.0 37 notes: 1. once corepci is granted the pci bus, the core asserts dp_start and begins the process of enabling the bus to drive framen. 2. the pci address and command are valid at the same time that framen is driven low. 3. once framen is driven, if the backend is prepared to supply data, then irdyn is asserted on the following cycle. the core can store up to two dwords of data. if the target ha s not responded with a trdyn when the second dword is read , then the core will cease reading as indicated by the rd_be_now signal de-asserting. 4. the core then waits for the target to complete the transfer by asserting trdyn. 5. the transfer continues until ei ther the transfer coun t is exhausted or th e target disconnects. 6. cycle termination is initiated by driving framen high. 7. the number of clock cycles from dp_start to framen as sertion can be increased by asserting stall_master. figure 22 zero-wait-state dma master write (write to the pci bus) clk framen ad[31:0] c_be[3:0] irdyn trdyn devseln par stopn 13 14 15 16 56 7 8 910 11 12 12 3 4 mem_address[23:2] mem_data[31:0] rd_be_now rd_be_rdy dp_start data3 data4 data5 data1 data2 data3 addr3 addr4 addr5 addr6 byte enables pd1 pd2 pd3 addr paddr cmd data0 add0 add1 add2 data0 data1 data2 pd0 dp_done rd_cyc barn_cyc
corepci v5.41 38 v4.0 backend control of dma activity the core provides two si gnals, busy_master and stall_master, that can be used to control the dma transfers. busy_master allows a dma transfer to be stopped, and stall_master allows for slow backends to meet the frame-to-irdy asse rtion requirement for pci. if the backend asserts busy_master when a dma transfer is taking place, the core will stop the dma transfer as soon as possible , as shown in figure 22a. due to pci protocol requirements the core may need to transfer an additional two words after busy_master has been asserted. the co re will not restart the dma transfer until busy_master has been de-asserted. the backend may assert be_req at the same time, and when be_gnt is asserted may acce ss the dma control registers. the backend can then clear the dma request bit in the control register to cancel the rest of the dma transfer. when a dma backend read cycle is started the core will start a backend read cycle by asserting dp_start and two cycles later assert fram e. once frame is asserted the pci specification requires that the core assert irdy within 8 clock cycles. the co re cannot assert irdy until the backend has asserted rd _be_rdy. if the backend asserts rd_be_rdy after 7 clock cycles, the core will violate the pci frame to irdy assertion timing. in this situation the backend should assert stall_master until it can assert rd_be_rdy, this will delay the core-asserting frame until data is ready, causing the frame to irdy delay to be less than 8 clock cycles. figure 23 dma master with busy_master asserted stall_master busy_master framen ad[31:0] cbe[3:0] irdyn trdyn stopn devseln dp_done rd_cyc mem_address[23:2] mem_data[31:0] rd_be_rdy rd_be_now addr data0 data1 data2 da ta3 cmd byte enables cmd addr0 addr1 addr2 addr3 addr4 addr4 data0 data1 data2 data3 data4 data4
corepci v5.41 v4.0 39 when stall_master is active (see figure 24 ), the core does not immediately assert frame and the pci bus is idle. it is possible for the pci gnt to go awa y; in this case the core will stop the pci transfer and assert dp_end. accessing the dma registers from the backend a write to the dma register is accomplished by asserting cs_controln, wr_controln, valid address, and valid data at the same time. registers can be updated one at a time or in bursts by changing the address and data while keeping cs_controln and wr_controln asserted ( figure 25 ). reads from the dma are pipelined with two cycles of delay between valid address and valid data. to enable the output drivers, both cs_controln and rd_controln must be driven low ( figure 26 ). figure 24 dma master with stall_master asserted clk dp_st art stall_master busy_master framen ad[31:0] cbe[3:0] irdyn t rdyn stopn devseln dp_done rd_cyc mem_address[23:2] mem_data[31:0] rd_be_rdy rd_be_now addr data0 data1 data2 cmd byte enables addr0 addr1 addr2 addr3 data0 data1 data2 figure 25 backend write to a dma register figure 26 backend read from a dma register clk we_controln cs_controln control_add[1:0] valid mem_data[31:0] valid 12 3 4 clk cs_controln we_controln control_add[1:0] mem_data[31:0] valid valid 1 2 34 56 78 910
corepci v5.41 40 v4.0 ordering information corepci v5.41 can be ordered through your local actel sales representative. it should be ordered using the following numbering scheme; corepci-xx where xx corresponds to one of the variables in table . table 23 ordering codes xx description ev evaluation version sn netlist for single-use on actel devices an netlist for unlimited use on actel devices sr rtl for single-use on actel devices ar rtl for unlimited use on actel devices ur rtl for unlimited use and not restricted to actel devices
corepci v5.41 v4.0 41 list of changes the following table lists critical changes that were made in th e current version of the document. datasheet categories in order to provide the latest information to designers, some datasheets are published before data has been fully characterized. datasheets are designated as "product brief," "advanced," and "production." the definitions of these categories are as follows: product brief the product brief is a summarized version of an advanced or production datasheet containing general product information. this brief summar izes specific device and family in formation for unr eleased products. advanced this datasheet version contains initial estimated information based on simulation, other products, devices, or speed grades. this information can be used as estimates, but not for production. unmarked (production) this datasheet version cont ains information that is considered to be final. previous version changes in current version (v4 . 0) page v4.0 proasic3/e data was added. ?
5172168-2/10.04 http://www.actel.com actel and the actel logo are registered trademarks of actel corporation. all other trademarks are the property of their owners. actel corporation 2061 stierlin court mountain view, ca 94043-4655 usa phone 650.318.4200 fax 650.318.4600 actel europe ltd. dunlop house, riverside way camberley, surrey gu15 3yl united kingdom phone +44 (0) 1276 401 450 fax +44 (0) 1276 401 490 actel japan exos ebisu bldg. 4f 1-24-14 ebisu shibuya-ku tokyo 150 japan phone +81.03.3445.7671 fax +81.03.3445.7668 actel hong kong 39th floor, one pacific place 88 queensway, admiralty hong kong phone +852.227.35712 fax +852.227.35999

▲Up To Search▲

Price & Availability of COREPCI-M

	To Download COREPCI-M Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .